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Abstract 

The U.S. Naval Observatory (USNO) Alternate Master Clock (AMC) became fully operational on 
23 July 1996. The AMC was relocated to Falcon Air Force Base (AFB) from Richmond, Florida, 
commencing 24 October 1995. By placing the AMC at Falcon AFB, the clock is co-located with the 
GPS Master Control Station and, thus, the primary means of global time dissemination. The AMC 
is in a key position to provide significant improvements to the various space systems operated by 
the Air Force from Falcon AFB. Efforts are underway to enhance the timing of GPS, the Air Force 
Satellite Control Network, and some TALON programs within the Space Warfare Center. The AMC 
will be able to provide a more reliable and robust timing source for all users at Falcon. This will 
eventually lead to reduced navigation errors, increased communications capability, and improvements 
in C4I. The areas in which the AMC will be used to enhance worldwide military operations are 
highlighted. 


INTRODUCTION 

The U.S. Naval Observatory (USNO) Alternate Master Clock (AMC) is the backup for the 
Master Clock maintained at USNO. The move of the AMC to Falcon Air Force Base (FAFB) 
occurred between October 1995 and July 1996. The AMC was previously located in Richmond, 
Florida. The clock was relocated for several reasons: 

1. Richmond, Florida, was highly susceptible to natural occurring problems, such as hurricanes 

2. Co locate with the Global Positioning System (GPS) 

3. Place in a more secure environment 

4. Provide a greater, more robust backup capability. 

The AMC is designed to provide precise time, on the order of 2-3 ns accuracy a day to the 
military commands located at FAFB. The primary user of AMC data is GPS. Additionally, the 
system provides timing reference signals to the 50th Space Wing communications squadron and 
the Air Force Technical Applications Center detachment. Plans are in place to provide precise 
timing reference signals to the Air Force Satellite Control Network, Space Warfare Center, and 
other satellite control systems. 
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This project was coordinated with the Air Force and serves to support the interest of both 
services. The AMC obtained initial operational capability in November 1995 and was made 
fully operational on 23 July 1996. The next major step in the development and operational 
use of this system occurred on 12 September 1996. On this date, the AMC provided a 5 MHz 
signal to the GPS Monitor Station located at the Master Control Station (MCS). 

WHAT COMPRISES THE ALTERNATE MASTER CLOCK 

The AMC primary equipment consists of 11 cesium atomic clocks, 2 hydrogen masers, 2 
Auxiliary Output Generators (AOGs), data analysis equipment, two-way satellite time-transfer 
systems, and distribution systems. The two master clocks at the AMC are the AOGs, with each 
AOG referenced to a hydrogen maser. The master clocks are named AMC #1 and AMC #2. 

Data on all AMC clocks are gathered using two separate data analysis systems: the Data Ac¬ 
quisition System (DAS) and the Timing Solutions Corporation Measurement System (TSCMS). 
The DAS compares all AMC and GPS clocks to AMC #1 and AMC #2 every 20 minutes, 
while the TSCMS compares the 5 MHz frequency of all AMC clocks to AMC #2 every 20 
seconds. These data are used both in the time scale and for analysis of clock performance. 

The AMC has three GPS receivers: two Precise Positioning Service (PPS) keyed and one 
Standard Positioning Service (SPS) unkeyed timing receiver. The PPS receivers are made by 
Stanford-Telecom and the SPS receiver is made by Allen Osborne Associates. The PPS receivers 
arc used to monitor the GPS satellite clock performance and provide a steering reference to 
AMC. The SPS receiver is used to conduct common-view time transfer between the AMC and 
USNO in Washington, DC. 

The AMC maintains the highest precision reference to UTC(USNO) using Two-Way Satellite 
Time Transfer (TWSTT). The means of distributing AMC to users is via a 5 MHz, 1 pps, 
or IRIG B distribution amplifier. Additionally, many outside users connect into the AMC 
using a fiber-optic cable. The AMC also has a redundant telephone voice announcing system. 
The phone number is (719) 567-6742. In the future, the AMC will have a computer modem 
capability. 

The AMC #1 has maintained time to within two nanoseconds of the USNO Master Clock in 
Washington, DC. This is made possible using the TWSTT system. Hourly the AMC and USNO 
establish communications via a commercial Ku-band satellite to exchange timing data. AMC 
#1 is then steered towards the Master Clock using a steering algorithm developed by Paul 
Koppang (USNO). AMC #2 is steered to USNO(GPS) using the data provided by a keyed 
Stanford-Telecom receiver. 


WHO NEEDS PRECISE TIME? 

Many users rely heavily on precise time and precise time intervals. For instance, GPS uses time 
at the nanosecond level for precise navigation and positioning of military units and weapon 
systems. The military communication system needs precise time at this same level for the 
synchronization of secure communications. 

Time is disseminated to Department of Defense (DoD) users by many means. USNO primary 
time dissemination means is using GPS, with over 95% of military users relying on this means 
of dissemination. GPS provides nanosecond level accuracy to users on a continuous global 
basis. Other methods of time dissemination and their accuracies include: 
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1. TWo-way Satellite Time Transfer (TWSTT) (nanosecond) 

2. IRIG-B (microsecond) 

3. Internet (millisecond) 

4. Computer modem (millisecond) 

5. Voice (second) 

6. PTTI Advisory Service (bulletins-postprocessed data). 


BENEFITS OF THE ALTERNATE MASTER CLOCK 

In the event of a loss of the USNO Master Clock, the AMC will be the time standard for 
DoD and will operate using an independent time scale. This time scale will be based on the 11 
cesium atomic clocks and 2 hydrogen masers. The AMC time scale is automatically computed 
hourly and manually computed twice per week. Many of the functions of the USNO Master 
Clock will be performed by the AMC; however, some may be conducted at a reduced level of 
support. 

The installation of the AMC has enabled the direct monitoring of the Falcon GPS Monitor 
Station cesium clock. The hydrogen masers located at the AMC allow for special testing with 
classified users. The hydrogen masers will maintain an accuracy of close to 80 picoseconds over 
a period of one week. Plans already exist to conduct a special timing test between the AMC 
and the Space Warfare Center. This testing should be completed within the next calendar year, 
with data available in 1998. 

Eventually, USNO plans to establish a distributed master clock. This distributed master clock 
will consist of the AMC time scale integrated into the USNO Master Clock. This will result 
in a more robust system and should improve the overall stability of the Master Clock. 


TIMING REQUIREMENTS 

The discussion of requirements must be addressed when referring to precise time and its uses. 
The needs within the DoD include, at a minimum, the following: 

1) Communications 

a) Secure and Crypto 

b) Increased bandwidth utilization 

2) Geo-location 

a) Remote sensors 

b) Combat ID 

c) Cooperative Engagement Capability (CEC) 

3) Navigation 
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4) Computers 

a) Data recording 

b) Network Time Protocol (NTP) 

c) ATM/SONET 


The impact of improved timing for GPS in the future is significant. The integration of timing, 
from GPS, will significantly enhance the war fighters capability to meet the challenges faced by 
the increased operations tempo. GPS in the cockpit will allow the pilot to not only improve 
his navigation picture, but also improve the quality and accuracy of his intelligence picture. 
Improved timing on the battlefield will reduce the likelihood of friendly fire or collateral 
damage. Remote sensors will realize the ability to provide precise intelligence data and to 
communicate these data to the war fighter with greater speed and accuracy. 

With the integration of good internal clocks for the GPS receivers, more reliable tracking 
during periodic loss of the GPS signal will be realized. These internal clocks will significantly 
improve the Y-code acquisition time for authorized users and require fewer satellites in view 
to maintain a good position. 

THE PTTI MEETING AND ITS PURPOSE 

Following this talk on the AMC, a significant discussion arose regarding the need for precise 
time and the focus of the PTTI Meeting in general. The requirement for precise time transcends 
many levels within DoD and the commercial market. The impact of computers on everyday 
life is well known; however, the need for precise time is not as well understood. For instance, 
the speed of a computer is directly tied to time. A 100 MHz computer will perform an internal 
operation every 10 nanoseconds. This is not as critical in a stand-alone mode as it is when 
operating within a distributed system or in a virtual engineering environment. Here remotely 
located computer systems must rely on accurate timing between the various systems in order 
to efficiently perform operations and transfer data. For commercial power companies, precise 
timing at the nanosecond level allows for the accurate location of a power line fault in times 
unimaginably short in the past. 

For the military, more accurate timing translates into putting ordnance on target and minimizing 
or even preventing collateral damage. In order to make this a reality, time must be known 
and transferred at the nanosecond level. The fact that light travels at 186,000 miles per second 
means a nanosecond equates to about one foot in linear distance. Thus, if two or three remote 
sensors identify the precise time of the occurrence of a unique event, relative to their location, 
then the exact position of this event will be realized and effective countermeasures may be 
launched. This assumes the sensors are all referenced to the same time. In terms of mine 
warfare, precise timing and navigation will prevent the damage or destruction of an ship as it 
transits a mine field. Why? Because the exact location of the enemy mines will be precisely 
known and units will then be able to avoid this area. 

In the case of ships at sea, timing is critical to communication and combat systems. For 
a given threat, the ship may have less then 30 seconds to detect the threat and provide the 
necessary response prior to suffering damage. The program manager responsible for developing 
this system provides the overall time line from detect to engagement to the contractors. But 
in many cases, the exact breakdown of the three major components in this scenario is not 
known or defined. Three major systems are key to the success and all rely on computers and 
distributed processing systems to operate properly: 1. Detection, 2. Command and Control, 
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3. Engagement. If each contractor designs their system to meet the overall time line (for 
instance, 30 seconds), then the ability of the system to counter the threat will not be realized. 
This problem, coupled with the additional ability to receive threat data from external sources, 
compounds the processing capabilities of today’s computer systems. Therefore, as stated earlier, 
the ability of a ship to respond to the threat may very well depend on the timing accuracy of 
the entire detect to engage system down to the nanosecond level. 

For the PTTI Meeting to be a success, the right people need to be in the audience. Today’s 
state-of-the-art equipment and high-speed weapons demand the attention of program managers, 
engineers, and system designers, both in government and industry. These people are not present. 
After all, what is the purpose of the PTTI conference? 



Questions and Answers 

ROBERT VESSOT (SMITHSONIAN ASTROPHYSICAL OBSERVATORY): I share your 
concern about the program management; I’ve lived long enough to work with NASA for the 
last 30 years. And I find that the deterioration of program management has gone to a level 
now where there is more concern with the PERT and the GANTT charts and the budgets 
than any conceivable interest, even, or understanding technically what is going on. Program 
managers in the bad old days - or I should think the good old days - used to be engineers 
that were working in the lab. And they managed outside contractors, but they had a very clear 
perception of what the goals were and how to get there. 

Now program management has been relegated to the MBA; and even though I’m at Harvard, I 
admire the school, but these are not the kind of people you want to manage technical programs. 
They have to be engineers at least somewhere along the line, or have access and appreciation 
for engineering. 

WILLIAM BOLLWERK: That’s correct. And that’s one of the problems we do face. When I 
was a program manager, I had GS-13s, 14s, and 15s who had no knowledge of the engineering 
that they were dealing with, much less how to manage it. 

JAMES CAMPARO (AEROSPACE CORP.): It seems we keep talking around this issue of a 
disconnect between high-level system requirements and lower-level PTTI requirements. And I 
guess one thought that came to me as you were speaking, would it be beneficial at future PTTI 
meetings to invite program managers and have a session on system requirements? Let them 
tell us what the overall system requirements are; and that would put us in a better position to 
try to translate those into lower-level PTTI requirements for them. 

WILLIAM BOLLWERK: That would be ideal because then you would get the same people 
in the room to be able to communicate. It would have to be a classified session. But the 
other thing we would have to face is, what program managers do we need to invite? We need 
to know what systems are coming down the line. So we would need assistance from several 
sectors, because I know I’ve stood in the same spot Commander Atkinson has here and have 
tried to find out the requirements. I went through all these operational requirement documents, 
these joint operational requirement documents and none of them addressed timing. Timing 
was a given; it’s going to be there; but none of them specifically stipulated that I have a timing 
requirement and I have a timing requirement in the nanosecond or picosecond or microsecond 
or millisecond level. 

So I think if we do get the program managers in here and we get some sponsors from the 
Pentagon in here, then maybe we can see some of these things put into some of these documents; 
and then maybe we can start heading in the right direction. 

LT. OMAR NAMOOS (USAF): I’ll just be brief. I come from the program management 
community. The thing about putting requirements on timing is - somebody mentioned it 
earlier - timing is really a derived requirement. I as a program manager have users, war 
fighters who do a task in the field. And I build my requirements - at least we’re trying to 
do it and we think it’s a smarter way - is to say, “build me a box that does this.” And that’s 
specified at the performance level. 

Timing is then the contractor’s responsibility to say, “In order to perform this function for you, 
I have the following derived timing requirement.” The military shouldn’t be in the business of 
doing that. 

CAPT. KENT FOSTER (USNO): As a career oceanographer and weather guesser. I’m used 
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to being in a lot of places where people don’t like me a lot because of what I have to say 
and the information I bring to them. That is true no place more so than it is in dealing with 
program managers that are building systems that are susceptible to the elements of weather in 
the ocean and combined effects. And after having dealt with these people for several years, 
I’m convinced that the big problem is that weather guessers don’t make life easier for operators 
or for people who design systems; they make life more difficult for them because they bring 
them problems that they need to overcome. 

And I think that’s the problem that we’re coming to grips with here with timing. We don’t 
make life easier for program managers, and it’s very, very easy and very desirable for them 
to ignore us to the extent that they possibly can and get away with it. And that’s a mindset 
that you really have to come to grips with and to reconcile and overcome. And I think that’s 
probably why there are not a lot of program managers here. 

PHILLIP TALLEY (RETIRED, AEROSPACE CORP.): In 1992, I made a rather sustained 
effort to organize a session for this PTTI that would bring in various major contractors like 
G.E. and Lockheed and so forth to let them explain how they went about through their 
systems engineering to specify time and frequency, not necessarily by a specific systems, but as 
a corporation how they went about doing this. And I got some early indication of cooperation, 
but absolutely no one actually participated. And I tried rather hard. 

WILLIAM BOLLWERK: It’s not going to be easy to get the program managers or those type 
of people in here, but that doesn’t mean that we should stop trying. We need to make it 
happen somehow. 

GERNOT WINKLER (INNOVATIVE SOLUTIONS INT’L): I think the core problem is that 
timing is an embedded requirement. And as you said, it is left to the contractor; that means 
that every contractor is going to solve it in his own way. This is a very expensive procedure; 
duplication is a consequence of that. And that is the reason why there is a PTTI instruction - 
or has been - in order to take it out and make sure that there is some coordination between all 
these individual embedded requirements which otherwise would solve the problem of bringing 
time to Hawaii or Kwajalein or wherever. We have to have a concentrating, coordinating center 
for that. 

CAPT. KENT FOSTER: I think the solution is embedded; there’s no doubt about it. But I 
don’t think that that’s a reason why the stated requirement should stay embedded. 

GERNOT WINKLER: No, no, I agree. 

RICHARD GRIFFIN (TEXAS INSTRUMENTS): A couple comments. We’re using the phrase 
“program managers.” I think the working people who do what you’re talking about are systems 
analysts, systems engineers. They’re the ones that provide the actual working interface between 
requirements that come down from operational command and the technologies that exist. That’s 
why I was asked to come to this program by my company, because that’s the interface area 
that I work. 

And the way we do it is with error budgets. As the Captain said, one of the biggest problems 
we face within companies and, frankly, with respect to the government, there is today a great 
horror about hearing about problems. If you go into a meeting and do an error budget and 
say, “We’re going to have a problem with this,” you’re going to get hit hard and fast because 
they don’t want to hear about problems; they don’t want anything that they feel will jeopardize 
the budget cycle, will jeopardize the political acceptability of a program, they’re not willing to 
listen to it. And, of course, it’s complicated by the fact, as we pointed out, that many of them 
don’t have the technical expertise, either because they are MBAs or they were engineers 30 


147 


years ago; and that’s the technology they remember, they haven’t kept up. 

But I think the people you need to bring in would be for a session on systems engineering 
associated with time. Because in my work what I have to do is take the overall requirements, 
derive an error budget, and then look at what the technology capabilities are to meet that error 
budget and go back. But often what I go back with is bad news or poor news. And you need 
support from there. 

RANDOLPH CLARKE (USNO): I have a thought on the idea of program managers here. 
I think any program managers we could get here probably don’t need to come here because 
they’ve already got the idea. So we should turn it around and try to determine where the 
program managers are in the first place, where do they meet, and send our people to their 
meetings and start opening this up. Eventually, then, we will get program managers here. But 
we have to make an outreach to where they are. They must have meetings like this. 

WILLIAM BOLLWERK: Actually, they don’t. There’s no central meeting of program managers. 
Program managers are enmeshed in their own programs to make sure that their programs are 
executable, as is pointed out, with the budgetary and other cycles. 

And also there’s the big picture of meeting with their sponsor in the Pentagon, who is the 
resource sponsor for their funds. And try to then coordinate meetings with the contractors in 
industry and the Fleet, in some cases, to make sure that everything kind of comes together. 

Program managers, though you said they probably shouldn’t be here - I tend to disagree with 
that because they’re going to help come up with the solutions; they’re going to force their 
people to come with the solutions one way or another. And if you don’t include them, then 
they may not appreciate the detail to which people have to go through to derive some of these 
requirements; because, they all are derived. And if we don’t derive them properly, a little 
nanosecond here, as you translate up into the big picture, gets lost, and pretty soon you don’t 
meet your threat or your requirement. 

HELMUT HELLWIG (USAF): Try to bridge this. I think I would ask this audience to listen 
to some of the comments, because if I look at the sequence of the discussion, it is as if one 
of the discussants hasn’t listened to the previous discussant. And I wanted to endorse what 
you said, it’s a systems engineering thing that we’re talking about, not a program management 
thing. Let’s have the definitions clear. There are meetings of program managers, and I’m 
participating in those; you don’t talk about this kind of thing, whether it’s time or any other 
technical detail. Time and frequency and clocks are tools of systems engineering, and in a big 
system they are, yes, an important tool, but one of many, many, many. And you need to get 
together a systems engineering forum, as you said, and try to bridge the gap between a tool of 
the systems engineer and the systems engineering community. Most of you are experts in the 
tool, and you need a link to the systems designer; that’s not the program manager, a program 
manager is not the systems designer. 

And in the future, by the way, as a consequence of acquisition from DoD, more and more 
of the requirements - in fact, the current goal is all requirements, as I think the Lieutenant 
pointed out - are performance requirements as seen by the war fighter. And it’s up to the 
contractor and the systems engineer to translate those into their particular system. And we 
will not, and DoD will refrain from specifying, what clock, what time system, what interface, 
except if it’s an interface that matters. 

DARRELL ERNST (MITRE CORP.): I think I can only support what this gentleman just said. 
I’ve worked in this area for many, many years, and it’s not the program managers. Program 
managers’ eyes glaze over even when they’re directly affiliated with the problem. 
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I feel that the problem is a lack of education at the engineering level. Many of the engineers 
that work these problems, these systems engineers, go to a catalog and they find a number of 
different off-the-shelf items that meet their requirements; if they don’t, they call around until 
they find somebody who’s willing to modify their equipment to make it work. And then they 
plug it together and they run their tests and they go on. And Joe White [NRLJ can support 
me, I think he watched me try to fight a problem in the AFSCN back in the ’80s when we were 
building Falcon Air Force Base. For years, they didn’t know it, but they were operating at the 
half a millisecond error in their timing systems because they were transmitting their IRIG-B 
code upside down. Engineers looked at it almost every day and didn’t know what they were 
looking at. 

It’s at the technical level that we have to solve this problem. Program managers are doing their 
job, they fight Congress and they fight all the different people that are forcing requirements 
creep on their projects; they don’t have time to worry about something to them that’s a tiny 
little part of a huge system. We did a requirements analysis on some comm protocols, and 
you go ask program managers, or even their systems engineers, and say, “What are your comm 
protocol requirements?” And they say, “What are you talking about, what’s a protocol?” 

And the same thing with time. We’ve got the problem here, not at the program manager level. 
You go to these contractors; the contractor is going to take a junior engineer and put him 
on this because we’re talking about one rack of equipment; he goes to the TRAK microwave 
catalog and he picks out his timing equipment; and he’s solved the problem, he thinks. 

JOHN VIG (ARL): Maybe what we need is a product liability law for military systems. Because 
when General Motors builds a car and gas tanks start exploding five years later, General Motors 
is still responsible, and gets sued, and they know it gets very expensive if they design a defective 
product. Unfortunately, in military systems it doesn’t work that way. After a system is 
delivered and things start going wrong, guess who pays? It’s always the taxpayer who pays, not 
the contractor who delivered that system. 

So, in an ideal world, I agree with Lt. Namoos that the government should not be specifying 
how a system should be implemented; they should be specifying only what the system should 
do. That’s absolutely the correct way of doing things. But if you do it that way, then you also 
have to have much better specifications for the system; and that specification probably should 
include lifetime beyond delivery of the system and incentives for ... 

CAPT. KENT FOSTER: Not being one to shy away from controversy, I’ll add one comment 
to this. I hear all that about the systems engineers, and I don’t disagree with it. But again, 
system engineers are the solvers of the problem. 

In my mind, there clearly has to be some accountability maintained over the systems engineers. 
And the person who is going to stand up and explain why the end performance level doesn’t 
match the requirement isn’t going to be the systems engineer, it’s going to be the program 
manager. And, therefore, the program manager needs to get more involved in addressing the 
requirement to the performance level. 

WILLIAM BOLLWERK: And to complement what the Captain just said, I think a clear 
example of that is Block HR and the satellite that’s going up in a couple months. It’s going up 
with one set of clocks on it; it was specified to have two different types of clocks: rubidium, 
cesium. And the fact is that it’s going up with only rubidiums. 

So if we have a problem with those clocks and that one set of system, then we’ve completely 
thrown away a satellite in space, it’s completely useless for navigation if those clocks were to 
fail. And that’s where if the program manager was probably more aware of the implications 
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between rubidiums/cesiums and having two different types of clocks on one satellite so that 
you don’t suffer a manufacturing defect failure or something else, then probably we wouldn’t 
be in that situation. We’ll have to see what happens when the satellite goes up, but that’s a 
potential problem with doing something like that. 




